Skip to content

feat: add client.Limits.MaxJOSECompactBytes for ID token/UserInfo size caps - #162

Merged
osanderson merged 1 commit into
mainfrom
feat/jose-compact-size-limit
Aug 26, 2026
Merged

feat: add client.Limits.MaxJOSECompactBytes for ID token/UserInfo size caps#162
osanderson merged 1 commit into
mainfrom
feat/jose-compact-size-limit

Conversation

@osanderson

Copy link
Copy Markdown
Collaborator

Summary

  • Makes the 16 KiB JOSE compact-serialization cap caller-configurable via client.Limits.MaxJOSECompactBytes, defaulted by RecommendedLimits(), following the same shape as Limits.MaxHTTPResponseBytes.
  • Scoped narrowly to the two artifacts whose size legitimately scales with granted scopes/claims — ID token and UserInfo response (signed and encrypted). DPoP proofs, client assertions, request objects, and JARM responses keep the package's fixed jose.DefaultMaxCompactBytes default, since those are fixed-shape by construction and unaffected by this change.
  • Adds the same size cap to the JWE decrypt path (jwe.DecryptRequest.MaxCompactBytes), which previously had no early bound of its own.
  • Splits out a new client.ErrorResponseTooLarge code so a caller can distinguish "response too large" from "malformed response" (previously both folded into ErrorInvalidResponse with a misleading "malformed JWS" message) — internal/jose being unexported meant there was previously no way to tell the two apart from outside the module at all.

Test plan

  • go build ./..., go vet ./..., go test ./... all clean
  • New unit tests: internal/jose.TestParseCompactMaxRespectsExplicitLimit, internal/jwe.TestDecryptRejectsOversizedCompact, client.TestFetchUserInfoRejectsSignedJWTOverConfiguredSizeLimit
  • Full local OIDF conformance run (conformance/scripts/run-all.sh): AS baseline (57 modules, 4465 conditions, 0 failures), AS message-signing (71 modules, 5975 conditions, 0 failures), RP baseline (22/22 PASSED), RP message-signing (28/28 PASSED)

https://claude.ai/code/session_013tGG2Ssuq5BDgCMbF8zYb8

…e caps

The 16 KiB JOSE compact-serialization cap was a hardcoded package
constant, but an ID token or UserInfo response scales with however many
scopes/claims an issuer was asked to grant, so a fixed limit that fits
one deployment can reject another's legitimate response. Make it
caller-configurable, following the same pattern as
Limits.MaxHTTPResponseBytes, and only for the two artifacts whose size
actually varies this way — DPoP proofs, client assertions, request
objects and JARM responses keep the package's fixed default since
they're fixed-shape by construction.

Also gives the JWE decrypt path (previously unbounded on its own) the
same cap, and splits ErrorResponseTooLarge out of ErrorInvalidResponse
so a caller can tell "too large" apart from "malformed" — internal/jose
being unexported meant there was previously no way to distinguish the
two from outside the module at all.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

@osanderson
osanderson merged commit 75c4943 into main Aug 26, 2026
8 checks passed
@osanderson
osanderson deleted the feat/jose-compact-size-limit branch August 26, 2026 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant